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Software  architecture  is  an  increasingly  in^oitant  research  topic  and  hi  iMsitpott  we  inve^gaie-  -  * 
the  potential  nrie  of  architecture  in  evaluating  the  properties  of  a  sy8|embui^  TO  a  partioite'rTCh^* '  ■ 

tecture.  Currently  such  architectural  analysis  is  couqrlicated  for  two  main  reasons:  autborS  Of  new'* '  ^  j 
architBctures  describe  their  creatioiis  in  idiosyncraiic  turns;  and  thesis  no  dear  way  of  omfet'-  '  ! 

standing  an  architecture  with  respea  to  an  otganization^s  life  cycle  concerns— eflfciency.  maiiil^*  *• 
Ability,  modifiability,  and  so  ftvih.  Hus  report  addresses  these  shortobmings  by  proposihg'a  '''  ! 
damtbi-based  method  for  analyzing  software  architecuues  called  SAAM  (Software  Architecture 
Analysis  Nfethod).  Hiis  method  contains  several  steps.  A  canonical  hmctioiial  partitioning  for  the 
domain  is  adopted.  Next,  some  candidate  architectures  in  this  domajn-are  described  in  a  common-  - 
and  simple  structural  language,  providing  a  nemtal  context  in  which  to  understand  their  similarities 
and  diflierenoes.  Next,  life  cycle  concetns  for  the  quality  of  the  resultant  softn^  are  detennined 
and  asetof  bendunark  tasks  we  created  which  embody  these  concerns.  Finally,  the  architectures 
we  evaluated  and  compared  with  respect  to  bow  well  they  support  the  benching  tasks.  This  report 
illustrates  the  method  by  analyzing  user  interface  archiiectures  with  respect  to  the  qu^ity  of  modi-  i 

fiability. 
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1  Introduction 

Sitftware  architecture  is  a  topic  of  growing  concern  within  both  research  and  industrial  circles. 
This  report  investigates  what  is  needed  in  an  architectural  description  of  a  system  in  order  to  eval¬ 
uate  it  with  respect  to  some  organizational  or  life  cycle  qualities. We  restrict  the  architectural  anal¬ 
ysis  to  systems  within  a  common  domain  and  within  that  domain  we  only  focus  on  one  of  many 
qualities  that  might  be  satisfied.  In  this  introduction  we  will  first  examine  why  architectural  analy¬ 
sis  US  difficult  and  how  our  method  of  evaluation  can  address  these  difficulties.  We  will  then  define 
three  perspectives  on  software  architecture  as  the  basis  for  describing  different  tools  in  a  common 
architectural  language.  Given  this  language  for  describing  architectures,  we  formulate  representa¬ 
tive  tasks  as  benchmarits  to  judge  an  instance  of  an  architecture  with  respect  to  the  software  qual¬ 
ity  of  concern. 

Throughout  this  paper  we  will  use  the  domain  of  user  interface  software  as  an  example  to  demon¬ 
strate  the  architectural  perspectives  and  the  method  of  using  benchmarks  to  assess  the  quality  of 
on  architecture.  Architectural  considerations  in  this  domain  are  important  as  much  of  the  pmgre.ss 
over  the  past  decade  in  die  development  of  user  interfaces  can  he  characterized  as  changes  to  the 
software  architecture  for  the  user  interface  portion  of  systems. 

User  interface  architectures  are  typical  of  architectures  in  other  areas  since  they  are  primarily 
motivated  by  organizational  or  life  cycle  qualities.  Examples  of  such  qualities  are  maintainability 
portability,  modularity,  reusability,  and  so  forth.  However,  it  is  often  difficult  to  assess  the  various 
claims  made  by  the  developers  of  these  architectures;  claims  such  as: 

Wa  have  developed . . .  user  interface  components  that  can  be  reconfigured  with  minimal 
effort.  (22] 

This  [rrKXlel]  allowe  the  UIMS  to  be  simple  and  irKiependent  of  the  graphics  software  and 
hardware  as  well  as  the  data  representation  used  by  the  application  program.  [32] 

Serpent ...  encourages  the  separation  of  software  systems  into  user  interface  and  “core” 
application  portions,  a  separation  which  wM  decrease  the  cost  of  subsequent  modifications 
to  the  system.  [25] 

This  Nephew  UIMS/Application  interface  is  better  that  [sic]  traditional  UIMS/Appfication  in¬ 
terfaces  from  the  modularity  and  code  reusabiNty  point  of  views.  [28] 

The  difficulty  in  a.s.sessing  the  validity  of  these  claims  ari.ses  for  a  number  of  reasons.  When  peo¬ 
ple  develop  new  architectures,  they  typically  develop  new  terms  to  describe  them,  or  u.sc  old 
terms  in  a  new  way.  As  a  result,  compari.son  with  existing  architectures  becomes  difficult — there 
is  no  level  playing  field.  Furthennorc,  linking  architectural  abstractions  with  life  cycle  concerns  is 
problematic.  Developers  tend  to  concentrate  on  the  functional  features  of  their  architectures,  and 
.seldom  address  the  ways  in  which  their  architectures  support  concerns  within  the  sy.stem  develop¬ 
ment  life  cycle.  Yet  another  problem  is  the  level  of  indirection  that  con  arise  becau.se  a  description 
for  a  tool  is  provided,  hut  what  we  really  want  to  asse.ss  is  the  quality  of  instances  of  systems 
designed  with  that  tool.  It  is  sometimes  difficult  from  the  literature  to  extract  what  architectural 
assumptions  the  developers  of  a  tool  have  placed  on  the  sy.stcms  which  that  tool  will  construct.  In 
proposing  a  method  to  evaluate  a  tool,  we  actually  mean  in  this  report  that  we  want  to  evaluate  the 
things  the  tool  helps  a  designer  to  build. 
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Tte  main  goal  of  this  paper  is  to  establish  a  method  for  describing  and  analyzing  software  archi¬ 
tectures,  Software  Architecture  Analysis  Method  (SAAM).  The  main  objectives  of  the  SAAM  are 
to: 

1 .  provide  a  clear  description,  in  a  common  language,  of  the  proposed  software  architec¬ 
ture  that  exposes  its  main  features  and  functionality; 

2.  within  a  particular  organizational  context,  understand  the  life  cycle  concerns  surround¬ 
ing  the  use  of  any  systems  developed  within  the  (noposed  software  architecture,  reveal¬ 
ing  which  non-functional  qualities  of  the  software  are  most  important; 

3.  introduce  benchmaric  tasks  as  concrete  instances  to  test  the  life  cycle  activities  which 
the  software  architecture  must  support; 

4.  evaluate  the  software  architecture  by  examining  its  performance  with  respect  to  the 
benchmark  tasks. 

In  Section  3,  we  define  three  perspectives  of  a  software  architectural  description:  the  functional 
partitioning,  the  structural  composition,  and  the  allocation  of  function  to  structure.  One  of  our 
main  concerns  for  describing  architectures  is  the  adoption  of  a  common  language  that  can  be  used 
to  define  all  architectural  instances.  Defining  these  three  perspectives  is  a  step  in  the  direction  of 
defining  such  a  common  architectural  language. 

A  secondary  goal  of  this  paper  is  to  demonstrate  the  utility  of  the  SAAM  for  the  evaluation  of  u.ser 
interface  architectures.  In  Section  4,  we  examine  several  candidate  functional  partitionings  for 
this  domain  (the  Seeheim  model  (211,  the  PAC  model  [4|  and  the  Arch/Slinky  model  [31])  and 
choose  the  latter  as  the  reference  architecture  to  examiire  the  strucuiral  composition  and  allocation 
for  various  influential  user  interface  architectures  in  the  research  community  (Serpent  [1],  Chiron 
[26],  and  Garnet  [12]). 

One  of  our  key  arguments  is  that  software  architectures  are  neither  intrinsically  good  nor  inuinsi- 
caily  bad;  they  can  only  be  evaluated  with  respect  to  the  needs  and  goals  of  the  organizations 
which  use  them.  Understanding  the  life  cycle  concerns  for  a  particular  organization  provides  a  list 
of  quality  factors  that  can  be  used  to  discriminate  between  good  and  bad  architectural  alternatives 
for  that  organization.  For  example,  in  the  Evolutionary  Development  Life  Cycle  project  at  Carn¬ 
egie  Mellon  University,  we  are  concerned  with  the  architecture  of  systems  which  have  long  pro¬ 
jected  lifetimes — 20-30  years.  This  is  an  increasingly  important  .segment  of  the  software  market. 
According  to  a  study  by  Green  and  Selby,  the  average  age  of  all  .software  is  increa.sing  [8].  In  .sys¬ 
tems  .such  as  the.se,  modifiability  is  of  paramount  importance.  For  this  reason,  we  evaluate  u.scr 
interface  architectures  with  respect  to  the  property  of  modifiability.  In  Section  5  we  di.scass  qual¬ 
ity  attributes  further  and  examine  modifiability  more  clo.sely,  developing  two  benchmark  tasks  in 
the  u.ser  interface  domain  which  shape  our  analysis.  The  u.se  of  modifiability  is  an  example,  albeit 
an  important  one  in  the  domain  of  u.scr  interfaces,  chasen  to  demon.strate  the  analy.sis  method. 
5>ection  6  completes  the  demonstration  of  our  analysis  method  as  we  compare  the  candidate  u.scr 
interface  architectures  with  respect  to  their  support  for  the  benchmark  tasks. 
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2  Related  Work 


Our  approach  to  the  analysis  of  software  at  the  architectural  level  reflects  a  growing  trend  in  soli- 
ware  engineering.  That  trend  emphasizes  a  better  understanding  of  general  architectural  concepts 
as  a  foundation  for  the  proof  that  a  system  meets  more  than  just  functional  requirements.  Perry 
and  Wolf  argue  that  an  architectural  description  fnovides  multiple  perspectives  of  different  infor¬ 
mation,  though  their  perspectives  would  rightly  be  considered  as  perspectives  on  structure  alone 
in  our  work  120].  They  promote  the  iLse  of  a  small  lexicon  of  elements  to  portray  structure  as  do 
others  [6],  [2].  In  devdoping  such  a  lexicon  in  this  report,  our  concern  was  for  adequacy  and  not 
completeress. 

Garlan  and  Shaw  have  demonstrated  how  the  examination  of  significant  architectural  case  studies 
can  help  to  define  the  field  of  software  architecture  [6].  Although  we  have  extensive  experience  in 
the  field  of  Human-Computer  Interaction  and  user  interface  development  and  analysis,  our  main 
interest  in  writing  this  paper  was  not  .so  much  for  the  HCI  community  but  for  the  general  software 
engineering  community  interested  in  understanding  how  clear  and  coherent  software  architectures 
can  aid  in  analy.sts.  We  offer  this  paper  as  a  case  study  of  software  architecture  analysis.  Tho.se 
with  different  architectural  concepts,  tools  and  methods  might  u.se  the  example  of  u.ser  inteifacc 
software  architectures  to  demonstrate  the  benefits  of  their  approach.  In  this  way,  the  problem  of 
evaluating  u.ser  interface  architectures  could  be  seen  as  a  touchstone  .similar  to  the  dining  philo.so- 
phers  problem  in  models  of  concurrency,  or  the  specification  of  elevators  in  formal  specification 
methods.  While  software  architecture  description  already  has  a  problem  domain  that  is  being 
adopted  as  a  reference  task  (compiler  design),  the  user  interface  architecture  domain  fulfills  a  dif¬ 
ferent  need — that  of  a  reference  task  for  software  architecture  evaluation  methods. 

Though  we  pre.sent  the  analysis  of  u.ser  interface  software  as  only  an  auxiliary  result  of  this  paper 
we  do  feel  it  is  necessary  to  relate  our  work  to  prior  analy.sis  work  in  u.ser  interface  architectural 
analysis.  Lane  provided  a  design  space  for  describing  various  u.ser  interface  architectural  .solu¬ 
tions  and  rules  for  choosing  which  architectural  alternatives  best  suit  a  given  set  of  design  criteria 
[13].  His  objectives  were  similar  to  ours  in  that  he  wanted  to  he  able  to  select  the  right  architec¬ 
ture  based  on  desired  quality  attributes.  However,  his  method  was  very  different  from  ours,  as  his 
results  were  based  on  an  expert  system  rule  base  which  codified  empirical  evidence  of  heuristic 
design  deci.sions  made  by  experienced  u.ser  interface  developers.  The  results  we  want  to  provide 
will  he  ba.sed  on  reasoned  argumentation,  and  on  demonstrated  performance  on  a  set  of  bench¬ 
mark  tasks.  One  could  argue  that  our  results  do  not  extend  Lane's  work  in  the  domain  of  u.ser 
interface  architectures.  That  would,  however,  be  missing  the  main  point  of  our  paper  how  to  carry 
out  an  architectural  analysis  in  any  domain. 

3  Perspectives  on  Architectures 

The  architectural  design  of  a  software  system  can  be  described  from  (at  least)  three  perspectives: 
the  functional  partitioning  of  its  domain  of  interest,  its  structure,  and  the  allocation  of  domain 
function  to  that  .structure.  These  perspectives  reflect  a  con.sen.sus  within  the  software  engineering 
community,  as  witnessed  by  the  literature: 
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[The  softwaie  architecture  level  of  deagn  addresses]  structural  issues  «ich 
as  gross  organization  and  global  control  structure;  protocols  for  communi¬ 
cation,  synchronization,  and  data  access;  assignment  of  functionality  to 
design  elements;  composition  of  components;  scaling  and  performance; 
and  selection  among  design  alternatives.  [6] 

Architectural  design  is  the  activity  of  partitioning  the  requirements  to  soft¬ 
ware  subsystems.  [26] 

Software  architecture  alludes  to  two  important  characteristics  of  a  com¬ 
puter  program:  (1)  the  hierarchical  structure  of  procedural  components  and 
(2)  the  structure  of  data.  Software  architecture  is  derived  through  a  parti¬ 
tioning  process  that  relates  elements  of  a  software  solution  to  parts  of  a 
reaJ-worid  problem  implicitly  defined  during  requirements  analysis.  [23] 

[Sy.stem  architecture]  shall  describe  the  internal  structure  of  the  system. 

The  segments  ...  shall  be  identified  and  their  purpose  summarized.  The 
relationships  among  the  segments . . .  shall  be  described.  [14] 

We  will  discu.ss  each  of  these  perspectives  in  the  next  three  subsections. 

3.1  Functioiiality 

A  system’s  functionality  is  what  the  system  does.  It  may  be  a  single  function  or  a  bundle  of  related 
functions  which  together  describe  the  system’s  overall  behavior.  For  large  systems,  a  partitioning 
divides  the  behavior  into  a  collection  of  logically  separated  functions  that  together  comprise  the 
overall  system  fiinc  jon  but  individually  are  simple  to  describe  or  otherwise  conceptuali29e. 

Typically,  a  single  system’s  funcuonality  is  decomposed  through  techniques  such  as  structured 
andysis  [33]  or  object  oriented  analysis  [23],  but  this  is  not  always  the  case.  When  discussing 
architectures  for  a  broader  domain,  such  as  we  are  doing  here,  the  functional  partitioning  is  often 
the  result  of  a  domain  analysis  for  a  class  of  similar  systems  in  that  domain.  One  sign  of  a  mature 
domain,  such  as  databases,  user  interfaces,  flight  simulators,  ATMs,  and  VLSI  design,  is  that  over 
time  some  function  partitionings  emei:ge  that  a  community  of  developers  adopt  That  is,  the  parti¬ 
tioning  of  functionidity  has  been  exhau.stively  studied  and  is  typically  well  understood,  widely 
agreed  upon,  and  canonized  in  implementation-independent  term.s.  In  Section  7,  we  discu.ss  some 
a.ssumptions  about  domain  analysis  and  functional  partitioning  which  would  lead  us  to  suggest 
that  more  than  one  partitioning  might  he  needed  to  evaluate  diflerent  qualities. 

3.2  Structure 

We  divide  a  system’s  software  structure  into  the  following  parts; 

1 .  A  collection  of  components  which  represent  computational  entities,  e.g.,  modules,  pro¬ 
cedures,  or  processes,  or  persistent  data  repositories; 

2.  A  representation  of  the  connections  between  the  computational  entities,  i.e.,  the  com¬ 
munication  and  conUY)!  relationships  among  the  components; 


6 


Figure  1  shows  the  conventions  we  use  in  this  report,  adapted  from  [1],  to  represent  the  structure 
of  a  piece  of  software.  Square-cornered  boxes  with  solid  lines  represent  processes,  or  independent 
threads  of  control.  Round-cornered  boxes  represent  computational  components  which  only  exist 
within  a  process  or  within  another  computational  component  (e.g.  procedures,  modules).  Square- 
cornered  shaded  boxes  represent  passive  data  repositories  (typically  files).  Round-cornered 
shaded  boxes  represent  active  data  repositories  (e.g.,  an  active  database).  Solid  arrows  reprc.sent 
data  (low  (uni-  or  bi-directional)  and  thick  grey  arrows  represent  control  flow  (also  uni-  or  bi¬ 
directional). 

Components  Connections 


Process 

(-•-)— 

Computational 

Q  J 

1  Component 

Passive  Data 

Repository 

^  \  Active  Data 

V  )  Repository 

U  ni-/Bi-directional 
Data  Flow 


Uni-/Bi-directional 
Control  Flow 


Figure  1:  Architectural  notations 

To  understand  the  overall  behavior  of  a  system,  we  need  to  provide  more  detailed  descriptions  of 
the  computations  possible  within  components  and  the  overall  coordination  of  a  collection  of  com¬ 
ponents  with  various  connection  relationships  between  them.  Such  computational  and  coordina¬ 
tion  models  should  be  explicit  and  described  separately  (!].  This  is  not  our  concern  in  this  paper, 
but  has  been  addressed  elsewhere  [2], 

3.3  Allocation 

The  allocation  of  function  to  structure  identifies  how  the  domain  functionality  is  realized  in  the 
software  structure.  The  purpose  of  making  explicit  this  allocation  is  to  understand  the  way  in 
which  the  intended  functionality  is  achieved  by  the  developed  system.  There  are  many  structural 
alternatives  and  many  possible  allocations  from  function  into  that  structure.  Software  designers 
choose  structural  alternatives  on  the  basis  of  system  requirements  and  constraints  which  are  not 
directly  implied  by  the  system’s  functional  description. 


4  Description  of  Architectures  for  User  interfaces 

With  this  background,  we  can  now  dc.scribe  a  number  of  .software  architectures  for  u.ser  interfaces 
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in  tenns  of  a  functional  partitioning,  structure  and  allocation  of  function  to  stnictuie.  Examining 
the  literature  on  user  interface  architectures  reveals  that  such  architectures  fall  into  two  classes, 
depending  on  whether  or  not  the  architecture  describes  an  actual  implementation  of  a  develop¬ 
ment  system.  Those  architectures  that  do  not  describe  an  actual  implementation  usually  serve  as 
reference  architectures  for  the  entire  domain  of  user  interfaces;  that  is,  they  are  sufficiently 
abstract  so  as  to  apply  to  a  wide  variety  of  implementations.  These  reference  architectures  (See- 
heim,  PAG  and  Arch/Slinky)  concentrate  on  the  essential  features  of  any  architecture  in  the 
domain  of  u,scr  interfaces.  In  our  language,  these  reference  architectures  serve  as  canonical  func¬ 
tional  partitionings  for  this  domain.  Though  they  do  imply  certain  structural  constraints  on  a  soft¬ 
ware  architecture  (for  instance,  see  the  remarks  in  Section  6.4),  that  is  not  their  main  contribution. 
We  adopt  one  of  them  (Arch/Slinky)  as  the  canonical  functional  partitioning  for  this  domain 
(though  we  consider  the  ramifications  of  selecting  PAG  in  Section  6.4). 

The  second  category  of  architectures  address  actual  implementations  of  user  interface  develop¬ 
ment  systems,  .so  we  can  describe  their  structure  and  allocation  (with  respect  to  the  Arch/Slinky 
functional  partitioning).  The  complete  architectures  we  describe  here  are  Serpent,  Ghiron  and 
Garnet.  We  expect  that,  over  time,  many  other  alternative  architectures  will  be  added  to  our  dis¬ 
cussion,  including  more  academic  systems,  such  as  UIDE  127]  and  Rendezvous  [II],  and  more 
commercially  recognizable  systems,  such  as  HyperCard  [7]  and  Visual  Basic  [5]. 

4.1  The  Seeheim  model 

The  term  UIMS  (User  Interface  Management  System)  was  given  wide  exposure  in  a  workshop  in 
Seeheim,  Germany.  Gonsequently,  the  model  upon  which  most  UIMSs  are  based  is  known  as  the 
Seeheim  model  [21].  This  model  shown  in  Figure  2. 


Figure  2:  The  Seeheim  Model 

The  three  main  components  in  this  mode?  are:  presentation,  dialogue  and  application  interface. 
The  dialogue  component  is  the  least  familiar.  It  is  essentially  an  organizer  of  traffic  between  the 
presentation  and  application-specific  components.  It  is  respon.sibic  for: 

•  maintaining  a  correspondence  between  objects  from  the  application  domain  and  interface 
objects  from  the  presentation  domain; 
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•  maintaining  relationships  among  the  interface  objects; 

•  maintaining  a  dynamic  repieseniaiion  of  the  state  of  the  dialogue  between  the  other  two 
components;  and 

•  defining  two  communication  proUKols,  one  suitable  for  the  functional  C(>re,  and  the  sec¬ 
ond  for  the  presentation. 

Dialogue  components  are  sometimes  modelled  with  special  purpose  languages  [3],  or  make  use  of 
special  functions  for  coordination  and  control  which  are  layered  on  top  of  an  existing  language 
(1151.  [26]). 

The  application  interface  component  performs  those  functions  that  are  inherent  to  the  application, 
irrespective  of  the  presentation  of  those  functions.  This  is  typically  written  in  a  high-level  lan¬ 
guage  such  as  C,  Fortran  or  Ada. 

The  presentation  layer  controls  the  end  user  interactions  and  generates  device-level  feedback  for 
the  user.  Typically,  a  UIMS  will  support  some  high-level  user  interface  toolkit,  such  as  the  X  tool¬ 
kit,  Sun’s  OpenLook  toolkit  or  the  Macintosh  toolkit 

The  Seeheim  model  does  not  provide  a  complete  description  of  a  user  interface  architecture.  The 
model  was  presented  as  a  logical  model  and  so  fits  our  description  of  a  functional  partitioning.  It 
has  withstood  the  test  of  time  and  may  therefore  be  deemed  a  canonical  partitioning  for  this 
domain.  Its  definition  is  not  complete  enough  to  uncover  structural  decisions,  though  there  cer¬ 
tainly  are  some  structural  relationships  that  we  can  infer.  It  is  confusing,  therefore,  that  we  have 
chosen  to  portray  it  graphically  in  a  language  that  is  similar  to  the  structural  language,  that  is,  with 
boxes  and  arrows.  The  reason  for  this  is  mainly  historical. 

4.2  The  Arch/Slinky  Metamodel 

The  Arch/Slinky  metamodel  of  user  interface  architectures  [3 1 1  is  an  extension  of  the  ba.sic  Sec- 
heim  model  and  identifies  the  following  five  basic  components  of  u.scr  interface  software: 

•  Functional  Core  (FC).  This  component  performs  the  data  manipulation  and  other  domain- 
oriented  functions.  It  is  these  functions  that  the  user  interface  is  exposing  to  the  u.ser.  This 
is  also  commonly  called  the  Domain  Specific  Component,  or  simply  the  Application. 

•  Functional  Core  Adapter  (FCA).  This  component  aggregates  domain  specific  data  into 
higher-level  structures,  performs  semantic  checks  on  data  and  triggers  domain-initiated 
dialogue  tasks.  The  FCA  is  similar  to  the  application  interface  in  the  Seeheim  model. 

•  Dialogue  (D).  This  component  mediates  between  the  domain  specific  and  pre.sentation 
specific  portions  of  a  mser  interface,  performing  data  mapping  as  nece.ssary.  It  en.sures  con¬ 
sistency  (possibly  among  multiple  views  of  data)  and  controls  task  sequencing. 

•  Logical  Interaction  (LI)  component.  This  component  provides  a  set  of  tooij^it  independent 
objects  (.sometimes  called  virtual  objects)  to  the  dialogue  component 

•  Physical  Interaction  (PI)  component  This  component  implements  the  physical  interaction 
between  the  u.ser  and  the  computer.  It  is  this  component  which  deals  with  input  and  output 
devices.  This  is  also  commonly  called  the  Interaction  Toolkit  Component 

The  Arch/Slinky  model  is  also  a  functional  partitioning,  hut  is  both  more  explicit  about  its  status 
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as  such,  and  more  fine-grained  than  the  Seeheim  model.  The  Arch/Slinky  functional  partitioning 
will  he  adopted  throughout  the  remainder  of  this  paper  as  the  canonical  functional  partitioning 
through  which  other  architectures  are  examined. 

4.3  PAC 

The  PAC  conceptual  model  for  interactive  systems  is  understood  as  follows:  an  interactive  system 
is  represented  as  a  collection  of  Presentation-Abstraction-Control  (PAC)  agents  which  are  related 
in  a  somewhat  (though  not  necessarily  strict)  top-down  hierarchical  structure.  Each  PAC  agent  tri¬ 
ple  represents  three  tightly  connected  comptments.  The  abstraction  component  contains  some 
applicadtm  relevant  piece  of  the  system,  the  presentation  component  sotire  interaction  relevant 
piece  and  the  control  component  maintains  a  presentation-abstraction  correspondence  within  the 
agent  Control  components  are  also  responsible  for  maintaining  compatibility  between  various 
PAC  agents  related  in  the  PAC  hierarchy.  Figure  3  shows  a  typical  PAC  structure. 


PAC  does  not  represent  a  tool  for  consuacting  user  interfaces;  it  is  still  just  a  conceptual  model. 
Because  PAC  is  closer  to  being  a  true  .software  architecture  than  either  Seeheim  or  Arch/Slinky, 
we  can  make  an  attempt  at  describing  its  structure  and  allocation  (with  respect  to  the  Arch/Slinky 
partitioning).  In  our  analysis,  we  must  assume  that  the  PAC  hierarchy  is  the  complete  description 
of  the  run-time  system,  so  it  mu.st  contain  all  of  the  roles  of  the  interactive  system  from  functional 
core  to  physical  interaction.  Later  models  of  PAC  (e.g.,  the  PAC-AMODEUS  model  [171)  have 
relaxed  this  con.straint,  viewing  the  PAC  model  as  a  way  of  decomposing  the  dialogue  component, 
which  .sits  within  the  larger  context  of  the  Arch/Slinky  meiamodcl. 

Thu.s,  in  order  to  evaluate  PAC  as  a  complete  software  architecture,  we  mu.st  postulate  a  software 
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structure  and  a  mapping  of  functionality  to  this  structure.  We  have  done  this  in  consultation  with 
an  expert  in  the  use  of  PAC  f  18].  Our  interpretation  of  PAC  as  a  complete  software  architecture  is 
given  in  Figure  4.  In  this  figure,  we  have  indicated  the  functional  roles  of  each  part  of  the  PAC 
hierarchy,  according  to  the  Arch/Slinky  functional  partitioning.  In  this  figure  we  have  redrawn  the 
components,  and  indicate  the  data  and  control  relationships  between  the  various  components 
using  the  notation  defined  in  Figure  I . 


The  application  component  of  the  topmost  (root)  PAC  agent  is  the  functional  core  of  the  system. 
There  is  no  presentation  component  in  this  agent,  because  the  pie.sentation  is  decomposed  in  the 
PAC  hierarchy.  This  is,  in  fact,  a  key  motivation  for  PAC — to  be  able  to  decompose  a  presentation 
and  its  accompanying  dialogue,  and  to  relate  pieces  of  dialogue  to  pieces  of  presentation  in  a  1:1 
fashion.  Separation  of  concerns  was  not  a  motivation  in  PAC,  which  is  why  PAC  agents  are 
tightly  coupled  (as  .shown  by  their  being  enclosed  within  a  common  computational  component). 
This  is  also  why  more  than  one  functional  role  may  exist  in  a  single  PAC  agent,  or  a  number  of 
functional  roles  may  be  spread  among  a  number  of  PAC  agents. 

Another  way  of  looking  at  this  partitioning  is  that  for  all  non-root  PAC  agents  in  the  system,  their 
main  purpose  is  to  partition  the  remaining  functional  roles.  Pre.scnialion  components  at  the  leaves 
of  the  hierarchy  fulfill  the  role  of  physical  interaction.  Thc.se  leaf  PAC  agents  would  not  nece.s.sar- 
ily  require  any  application  component  to  be  pre.sent,  as  is  depicted.  Responsibility  for  dialogue 
control  is  di.stributed  among  the  control  components  throughout  the  PAC  hierarchy.  The  func¬ 
tional  core  adaptor  and  the  logical  interaction  components  are  not  explicitly  rcpre.sented  in  PAC, 
although  they  do  exi.si  explicitly  in  the  PAC-AMODEUS  model. 
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4.4  Serpent 

The  three  types  of  components  which  are  identified  in  the  Sceheim  model  of  a  UIMS  and  which 
have  been  realized  as  distinct  processes  in  the  Serpent  architecture  i3],aiie  shown  in  Figure  5:  a 
dialogue  controller,  a  presentation  and  an  application. 


Figure  5:  The  Seipeni  architecture  (adapted  from  [3]) 

Application  modules  contain  the  computational  semantics  required  for  some  domain  application. 
Although  there  can  theoretically  be  many  different  applications  contained  within  a  given  run-time 
instance  of  Serpent,  there  is  typically  only  a  single  application.  Presentation  modules  repre.sent 
independent  techniques  for  supporting  interaction  at  both  the  logical  and  physical  level  com¬ 
pletely  independent  of  application  semantics.  Different  presentation  modules  in  a  given  run-time 
instance  are  possible,  although  once  again,  not  typical.  Given  that  application  and  presentation 
modules  are  separate,  there  must  be  a  way  to  coordinate  a  given  application  component  with  a 
pre.sentation  component  That  is  the  purpose  of  the  dialogue  controller.  The  dialogue  component 
mediates  the  u.ser’s  interaction  with  un  application,  through  the  control  of  the  pre.scntation. 

All  communication  between  Serpent  components  is  mediated  by  constraints  on  shared  data  in  the 
databa.se  shown  in  Figure  5.  This  structure  is  implemented  as  an  active  databa.se — when  values  in 
the  database  change,  they  are  automatically  communicated  to  any  component  which  is  registered 
as  being  interested  in  the  data.  This  global  database  phy.sically  resides  in  the  .same  proce.ss  as  the 
dialogue  controller  but  is  logically  independent  from  all  of  the  Serpent  components. 

Figure  6  indicates  how  the  five  basic  functional  roles  of  a  u.scr  interface  architecture,  as  identified 
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in  Section  3. 1,  are  mapped  onto  Serpent’s  software  structure.^ 


Figure  6:  Serpent  architecture  with  functional  roles  annotated 


There  are  several  points  of  interest  to  note  in  this  re-characterization  of  Serpent’s  structure: 

•  there  is  no  structural  separation  between  the  PI  and  LI  roles  in  the  presentation  compo¬ 
nent; 

•  there  is  no  structural  separation  between  the  FCA  and  D  components  in  the  dialogue  con¬ 
troller  component; 

•  all  of  Serpent’s  components  ate  monolithic — diat  is,  they  provide  no  arthitectural  support 
for  subdivision  of  functionality  within  a  component. 

It  is  important  to  note  that  architectural  support  is  only  one  type  of  support  that  might  be  provided 
for  subdivision  of  functionality.  A  system  may  provide  language,  design  or  tool  support  for  this 
purpo.se,  for  example.  We  do  not  deal  with  these  topics  in  any  detail  here,  but  recognize  them  as 
important  outstanding  research  areas. 

4.5  Chiron 

The  Chiron  architecture  [29]  was  built  with  the  expre.ssed  goals  of  uddres.sing  life  cycle  concerns 
of  maintainability  and  sen.sitivity  to  environmental  changes.  A  Chiron  architecture  consists  of  a 


1.  Doued  lines  are  used,  in  this  and  following  figuies,  as  a  visual  indication  of  the  allocation  of  functionality  to 
portions  of  the  suncture.  This  is  done  for  analysis  puiposes  only  and  should  not  he  interpreted  as  having  any  fur¬ 
ther  significance. 
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client  and  a  server.  The  client  consists  of  an  application,  which  exports  a  number  of  abstract  data 
types  (ADTs)  which  Chiron  encapsulates  within  Dispatchers.  Dispatchers  communicate  with  Art¬ 
ists.  which  maintain  ab.stract  representations  of  their  associated  ADTs  in  terms  of  an  abstract 
depiction  library  (ADL). 

A  Chiron  .server  consists  of:  the  ADL;  a  virtual  window  .sy.stem,  which  translates  from  abstract 
interface  depictions  into  concrete  ones;  and  an  instruction/event  interpreter.  The  instruction/event 
interpreter  responds  to  requests  from  Artists  to  change  the  abstract  description  and  translates 
those  requests  into  changes  to  the  pre.sentation.  It  also  responds  to  events  from  users  and  translates 
those  back  into  Artist  requests. 

A  typical  Chiron  nin-time  architecture  is  shown  in  Hgure  7. 


Rgure  7;  A  typical  Chiron  architecture  (adapted  from  [29]) 


The  Chiron  architecture  clearly  separates  the  application  (functional  core)  from  the  rest  of  the  sys¬ 
tem,  as  would  be  expected  in  a  system  which  was  built  with  the  exprc.ssed  goal  of  minimizing  .sen¬ 
sitivity  to  environmental  changes.  The  functional  core  adapter  could  live  in  the  ADTs,  or  in  the 
Artists.  It  .seems  clear  that  the  Artists  contain  .some  of  the  dialogue,  for  example,  maintaining  a 
correspondence  between  objects  from  the  application  domain  and  interface  objects  from  the  pre¬ 
.sentation  domain.  However,  what  is  less  clear,  from  the  architectural  de.scription,  is  where  the 
“state”  of  the  dialogue  lives.  For  example,  where  does  one  put  the  information  that  the  “paste” 
option  in  an  edit  menu  should  be  grayed  out  unless  something  has  previously  been  cut  or  copied? 
Another  type  of  dialogue  issue  is  maintaining  relationships  among  the  interface  objects.  For 
example,  when  a  user  selects  the  “Save  As”  option  in  a  hie  menu,  something  in  the  dialogue  must 
cause  a  file  .selection  box  to  be  created.  Once  again,  the  location  of  the.se  sorts  of  dialogue  i.ssues  is 
not  clear  from  Chiron’s  architectural  de.scription.  These  dependencies  might  exist  in  the  Artists,  in 
the  ADTs  or  even  in  the  Abstract  Depiction  Libraries  [30|. 
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The  physical  interaction  component  appears  to  be  located  in  Chiron’s  Virtual  Window  System 
component,  and  the  logical  interaction  component  is  encapsulated  within  die  ADL.  As  a  result  of 
this  characterization,  we  can  provisionally  annotate  the  Chiron  architecture  as  shown  in  Figure  X. 


Figure  8:  Chiron  architecture  with  functional  roles  annotated 


This  re-characterization  indicates  the  logical  division  of  functionality  in  Chiron,  according  to  the 
Arch/Slinky  meta-model.  Note  that  by  re-characterizing  Chiron’s  architecture  in  this  way,  we  can 
now  begin  to  understand  its  relationships  to  other  aichitecture.s,  such  as  Serpent’s.  This  tusk  is 
considerably  more  difficult  when  trying  to  compare  architectures  based  upon  their  own  represen¬ 
tations  and  claims.  What  we  have  done  is  to  develop  a  common  language  for  making  architectural 
comparisons. 

4.6  Garnet 

The  emphasis  of  Garnet’s  architecture  is  on  control  of  the  runtime  behavior  of  interaction  ohjccLs 
and  the  visual  aspects  of  the  interface  [IS].  This  is  a  dilTercnt  emphasis  from  the  two  previous 
architectures.  Serpent  and  Chiron,  which  were  expie.ssly  interested  in  maintainability  and  separa¬ 
tion  of  concerns. 

Garnet’s  architecture  consists  of  a  .single  proce.ss,  with  Common  Lisp  and  the  X 1 1  window  system 
as  its  functional  foundations.  On  top  of  this  base  the  Garnet  toolkit  has  been  con.structed,  and  on 
top  of  the  toolkit  are  high-level  Garnet  tools  (which  can  bo  thought  of  as  applications).  Garnet  is 
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thus  commonly  presented  as  a  layered  system,  as  shown  in  Figure  10. 


Garnet  Applications 
Widget  set 

Interactors  Opal  Graphics 

Constraint  system 
KR  object  system 

Xll _ Common  Lisp 

Operating  System 


Figure  9:  The  Garnet  architecture  (adapted  from  [IS]) 


However,  Garnet  is  not  a  strictly  layered  system.  In  a  strictly  layered  system,  the  nth  layer  hides 
all  details  of  the  layers  n-I  and  lower,  and  provides  services  to  layer  n-«-/.  In  Garnet,  Common 
Lisp,  the  KR  object  system,  and  the  constraint  system  ate  used  directly  by  all  layers.  The  Inierac* 
tors  and  Opal  Graphics  together  strictly  hide  all  of  the  XI 1  calls.  Thus,  the  widgets  and  applica¬ 
tions  do  not  have  any  operating  system  or  window  manager  calls  in  them,  only  calls  to  the 
interactors,  object-oriented  graphics,  constraints  and  ob^t  system  [16]. 

Given  this  analysis,  we  can  redraw  Garnet’s  architecture  as  follows: 


Figure  10:  The  Garnet  arcn;L.<.^ure  with  functional  roles  annotated 


The  Xll  window  .system  is  Garnet’s  physical  interaction  component  The  widget  .set  interactors 
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and  Opal  graphics  collectively  comprise  Garnet’s  logical  intetaction  component,  and  make  use  ol' 
the  object  and  constraint  systems  as  services.  Rnally,  applications  in  Garnet  aie  built  on  top  ol  the 
logical  interaction,  object  and  constraint  component  “layers”,  potentially  utilizing  the  services  ol 
all  of  those  layers.  The  arrows  in  Figure  10  have  been  deliberately  drawn  as  though  they  con¬ 
nected  the  entire  layers  together,  rather  than  showing  separate  arrows  between  each  of  the  ele¬ 
ments.  This  is  because  Garnet  provides  the  object  and  constraint  systems  and  logical  interaction 
components  as  services  which  are  potentially  available  to  all  layers,  rather  than  as  ei^apsulated 
structures.  By  way  of  comparison,  the  physical  interaction  component  of  Garnet  is  strictly  hidden 
from  the  other  layers — it  can  only  be  accessed  through  the  widget  set.  interactors  and  Opal  graph¬ 
ics. 

Note  that  we  have  removed  any  reference  to  Common  Lisp  in  our  re-characterizittion  of  Garnet 
This  is  because  Common  Lisp  is  the  language  of  implementation  which  all  components  use, 
rather  than  a  distinct  structural  entity.  Similarly,  we  have  removed  reference  to  the  underlying 
operating  system. 

This  characterization  of  Garnet  illustrates  several  points:  Garnet  subdivides  dialogue  functionaiity 
into  three  distinct  parts  and  logical  interaction  functionality  into  three  distinct  parts.  Application 
functionality,  however,  is  not  subdivided,  and  is  not  separated,  in  specification  or  at  runtime,  from 
the  rest  of  the  system.  Noting  where  an  architecture  subdivides  its  functionality  beyond  what  the 
domain  analysis  does  indicates  the  emphases  of  the  architecture.  The  subdivision  is  the  architec¬ 
tural  manifestation  of  the  stated  goals  of  Garnet:  control  of  the  runtime  behavior  of  interaction 
objects  (dialogue)  and  the  visual  aspects  of  the  interface  (physical  interaction  and  logical  interac¬ 
tion  components). 

Also,  it  is  interesting  to  note  that  Figure  10  has  actuaUy  been  simplified  somewhat:  the  connec¬ 
tions  between  the  FCVFCA/D  component  and  the  LI  component  is  shown  as  a  single  link.  In  fact, 
each  of  the  subcomponents  could  be  linked  with  any  of  the  other  subcomponents:  interactors  may 
make  use  of,  for  example,  the  KR  object  system  and  tire  constraint  system;  Garrret  applications 
may  make  use  of  the  KR  object  system,  the  constraint  system,  the  interactors,  widgets  or  Opal 
graphics. 

5  Analyzing  Architectural  Qualities 

Architectures  are  not  created  for  abstract  purposes.  They  are  typically  created  in  response  to  a  per¬ 
ceived  need,  or  shortcoming  with  existing  software  approaches  to  a  problem.  >Mth  this  in  mind,  it 
is  clear  that  a  method  for  evaluating  architectures  must  take,  as  its  starting  point,  a  particular  qual¬ 
ity  or  set  of  qualities.  Architectures  can  then  be  evaluated  with  respect  to  how  well  they  support 
these  qualitie.s. 

The  SAAM  (Software  Architecture  Analysis  Method)  thus  consists  of  five  distinct  steps: 

1 .  Characterize  the  functional  partitioning  for  the  domain. 

2.  Map  tire  functional  partitioning  onto  the  architecture’s  structural  (tecomposition. 

3.  Choose  a  set  of  quality  attributes  with  which  to  assess  the  architecture. 

4.  Choase  a  set  of  concrete  tasks  which  test  the  desired  quality  attributes. 
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5.  Evaluate  the  degree  to  which  each  architecture  provides  support  for  each  task. 

The  firs*  ’wo  steps  of  this  architecture  were  demonstrated  in  Section  4.  We  will  demonstruic  the 
rest  of  the  SAAM  in  the  coming  sections. 

5.1  Choosing  a  Set  off  Quality  Attributes 

In  order  to  analyze  architectures  for  a  particular  quality  attribute,  it  is  necessaiy  to  understand  the 
implications  of  that  attribute.  Once  this  is  done,  a  generic  set  of  tests,  or  benchmarks,  which  char¬ 
acterize  that  attribute  can  be  designed,  and  the  architecture  can  be  evaluated  in  terms  of  this 
benchmark  suite.  We  will  exemplify  this  process  with  respect  to  the  attribute  of  modifiability.  This 
benchmark  suite  could  have  bem  created  with  respect  to  other  attributes — portability,  efficiency, 
security,  and  so  forth.  We  have  chosen  modifiability  both  because  of  the  previously  mentioned 
emphasis  on  evolutiofuuy  systems  and  because  it  is  an  oft-cited  motivation  for  user  interface 
architectures. 

‘^Modifiability”  by  itself  is  an  abstract  concept  In  order  to  understand  how  to  design  for  modifi¬ 
ability,  it  is  necessary  to  better  understand  the  ramifications  of  this  attribute.  In  order  to  accom¬ 
plish  this,  we  look  at  what  sorts  of  modifications  to  a  software  system  in  our  domain  are  po.ssihie. 
When  that  is  accomplished,  we  then  decide  what  sorts  of  modifications  are  likely,  or  representa¬ 
tive  of  the  domain.  Then  a  sample  set  of  modifications  can  be  posited,  and  each  candidate  archi¬ 
tecture  can  be  evaluated  according  to  how  well  they  support  each  sample  modification.  This  set  of 
posited  modifications  becomes  a  benchmark  for  ail  architectures  within  the  application  domain.  If 
the  application  domain  is  well  understood,  the  bcmchmaric  set  of  modifications  can  often  be  given 
a  sample  distribution,  for  the  purposes  of  ranking  the  individual  evaluations  within  the  posited  set. 

Oskarsson  gives  an  informal  characterization  of  classes  of  modifications  in  [19].  Drawing  upon 
his  worit.  we  have  enumerated  the  following  class  s  of  modifications: 

•  Extension  of  capabilities’,  adding  new  functionality,  enhancing  existing  functionality  ; 

•  Deletion  of  unwanted  capabilities:  e.g.  to  streamline  nr  simplify  the  functionality  of  an 
existing  application; 

•  Adaptation  to  new  operating  environments:  e.g.  pmccs.sor  hardware,  I/O  devices,  logical 
devices 

•  Restructuring:  e.g.  rationalizing  system  servKes,  modularizing,  optimizing,  creating  reas- 
able  components. 

5.2  Choosing  a  Set  off  Concrete  Tasks 

The  next  step  in  an  analysis  of  an  architecture’s  suitability  for  modifiability  is  to  characteri/e  the 
particular  types  of  modifications  which  are  likely  within  the  domain.  In  the  user  interface  domain, 
two  classes  of  modifications  prove  most  common: 

•  Because  luser  interface  ctevelopment  is  highly  iterative,  extensions  of  capabilities  (adding 
new  features,  reorganizing  the  appearance  of  the  interface,  reorganizing  the  human-com¬ 
puter  dialogue)  are  rampant  This  is  particularly  so  during  the  initial  development  of  a  u.ser 
interface,  hut  such  modifications  are  also  common  later  in  the  life  cycle. 
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The  iterative  nature  of  the  user  interface  life  cycle  is  distinguished  from  typical  software 
engineering  life  cycles  in  that  it  is  more  based  upon  empirical  testing  and  validation,  and 
more  based  upon  |m>totyping.  Requirements  for  the  human-computer  interaction  portion 
of  a  system  are  often  not  well  understood  in  advance,  and  so  iteration  and  prototyping  arc 
often  the  only  ways  in  which  to  evolve  a  system’s  design.  For  this  reason,  the  user  inter¬ 
face  life  cycle  has  often  been  characterized  as  a  “star'’  shaped  life  cycle  [  12],  as  shown  in 
Figure  M ,  in  contrast  to  the  typical  software  engineering  lil'e  cycle  models,  which  are  rep¬ 
resented  as  “waterfalls”  or  “spirals”. 

•  Adaptation  to  new  operating  environments  is  also  a  common  modiBcation  activity  which 
user  interface  architectures  must  support  For  example,  this  paper  is  being  composed  using 
a  desktop  publishing  system  which  is  available  on  Unix-based  workstations  running  the  X 
window  system.  Macintoshes  running  the  Macintosh  toolkit  and  IBM-compatible  PCs, 
rutming  MS-Windows.  In  each  of  these  cases,  the  underlying  functionality  of  the  system  is 
identical.  What  does  change  is  the  devices,  both  logical  and  physical,  which  the  user  uses 
to  interact  with  the  program. 


Figure  1 1 :  The  star  life  cycle 


The  other  clas.ses  of  modifications  identified  in  the  previous  section — restructuring  and  deletion 
of  unwanted  capabilities — while  not  unknown,  do  not  constitute  a  significant  percentage  of  the 
modifications  which  user  interfaces  undergo.  We  will  not  include  them  in  our  set  of  modifications. 

Consequently,  with  this  set  of  modifications  in  mind,  we  can  now  analyze  the  ramifications  of 
each  type  of  modification  on  each  architecture.  We  do  this  by  choosing  a  .set  of  concrete  tasks 
which  test  the  desired  quality  attributes. 

This  pmce.ss  is  akin  to  choosing  a  .set  of  benchmark  tasks  through  which  a  piece  of  .software  or 
hardware  may  be  evaluated.  The.sc  modifreations  are  intended  to  approximately  model  the  type 
and  distribution  of  tasks  which  are  typical  of  ones  own  .software  development  life  cycle.  This  is 
why  a  set  of  example  modifications  is  required. 


19 


5^1  Changing  ttM  Physical  lnt»raction 

One  type  of  modiHcation  which  is  common  to  user  interfaces  is  changing  the  physical  interaction 
component — typically  the  toolkit  and/or  windowing  system  used.  Thus,  the  first  modification 
exemplar  which  we  examine  is  a  change  to  the  physical  interaction  component  For  example,  a 
move  from  using  Motif  to  OpenLook  or  the  Macintosh  toolkit  would  be  typical  of  this  category  of 
modification.  This  modification  manifests  itself  as  a  complete  replacement  of  the  physical  interac¬ 
tion  component  Note  that  one  assumption  underlying  this  sample  modification  is  that  all  interac¬ 
tion  behavior  required  by  the  logical  interaction  component  can  he  met  by  any  of  the  chosen 
physical  interaction  components. 

S.2J2  Changing  th«  OlalogiM 

The  next  exemplar  modification  is  an  extension  of  capabilities.  This  class  of  change  is,  we 
assume,  the  most  common  (and  hence  most  cosdy  overall)  change  in  the  user  interface  life  cycle. 

This  modification  manifests  itself  as  a  change  within  a  single  functional  role,  namely  the  dialogue 
component  Our  example  modification  is  to  add  a  single  option  to  a  menu,  reflecting  some  piece 
of  application  functionality  which  must  be  made  available  to  a  user. 

6  Analysis  of  Architectures  for  User  Interfaces 

Now  that  we  have  enumerated  our  set  of  benchmark  tasks,  we  arc  in  a  position  to  evaluate  the 
degree  to  which  each  of  our  candidates  provides  architectural  support  for  these  modifications. 

6.1  Serpent 

6.1.1  Changing  the  Physical  Interaction 

Changing  the  physical  interaction  component  in  Serpent  assumes  that  we  have  an  application  run¬ 
ning  under  one  toolkit  and  we  want  to  change  to  another  which  is  .supported  within  the  Serpent 
run-time  environment  For  example,  this  situation  would  occur  if  we  had  Motif  running  in  one 
Serpent  PI  component  and  OpenLook  in  another.  What  would  have  to  change  in  this  in,stance  is 
the  binding  between  an  application  and  its  physical  interaction  toolkit  It  is  not  clear  from  the 
architecture  of  Serpent  how  this  binding  is  achieved.  However,  it  is  rca,sonable  to  a.s.sumc  that  this 
link  is  achieved  by  the  dialogue  controller  component  which  accc.s.scs  data  in  the  global  shared 
data  structure  that  was  placed  there  by  application  and  pre.sentation  modules.  Therefore,  changes 
to  the  dialogue  component  would  he  the  only  neccs.sary  modification  to  accommodate  the  switch 
from  one  toolkit  to  another.  If  the  dialogue  was  written  utilizing  a  sufficiently  abstract  .set  of  vir¬ 
tual  tibjecLs,  no  changes  to  the  dialogue  would  be  nece.ssitated.  Howevec  Serpent  makes  no  archi¬ 
tectural  provi.sion  for  this:  the  LI  and  PI  components  arc  combined  into  a  single  run-time  entity. 
The  architecture  does  en.sure  that  the  PI  component  is  i.solated  from  the  rest  of  the  system,  which 
minimizes  PI  dcpendencie.s. 


20 


6.1.2  Changing  th«  dIalogtM 


Serpent  hax  isolated  the  dialogue  controller,  so  it  is  easy  to  say  that  the  second  moditicaiion 
type — adding  an  option  to  a  menu — will  occur  somewhere  in  that  module  of  the  system.  But 
exactly  where  the  change  resides  may  he  mote  difficult  to  determine  as  Serpent  dictates  no  furthei 
structure  to  the  dialogue  component.  Our  conclusion  is  that  Serpent’s  architecture  provides  no 
architectural  support  for  the  change  beyond  isolating  it  to  the  monolithic  structure  of  its  dialogue 
controller  module.* 

6.2  Chiron 

6.2.1  Changing  tha  Phyaicai  intaraction 

Chiron  goes  one  step  beyond  Serpent  in  providing  architectural  support  for  changing  the  PI  com¬ 
ponent  Chiron  has  isolated  both  the  PI  component  and  the  LI  component  in  separate  structures 
within  a  Chiron  server.  Since  the  Virtual  Window  System  only  communicates  with  the  Instruc¬ 
tion/Event  Interpreter  and  its  associated  Abstract  Depiction  Library,  it  is  isolated  from  the  rest  of 
the  architecture.  This  architectural  isolation  means  that  the  LI  and  PI  components  are  logically 
and  physically  .separate,  and  therefore  must  communicate  via  a  well-defined  interface.  The  exist¬ 
ence  of  such  an  interface  means  that  other  PI  components  could  he  inserted  into  the  architecture 
as  long  as  they  comply  with  the  interface  conventions. 

This  strict  .separation  of  concerns  aids  modifiability,  by  locali/.ing  the  effects  of  a  change.  Thus, 
we  can  conclude  that  the  Chiron  architecture  provide  .significant  support  for  changing  the  PI 
component. 

6.2.2  Changing  ttw  dialogtM 

Chiron  fares  slightly  less  well  with  respect  to  the  %cond  modification.  As  stated  in  5^ction  4.5. 
the  division  of  dialogue  responsibilities  between  Artists  and  ADTs  is  not  precisely  specified. 
Hence,  a  modification  to  the  dialogue  may  manifest  itself  as  a  change  to  an  Artist,  or  a  change  to 
an  ADT,  or  both.  If  the  ADTs  are  well-structured,  changes  to  them  should  be  minimal,  in  which 
case  a  change  to  the  dialogue  would  be  isolated  to  the  Artists.  Chiron  does  provide  support  for 
such  a  modification  in  that  Artists  are  a.s.sociated  with  individual  ADTs,  and  .so  there  is  no  mono¬ 
lithic  dialogue  to  modify.  However,  since  it  is  not  clear  whether  a  change  will  affect  an  Artist,  an 
ADT,  or  both,  we  cannot  claim  that  a  strict  .separation  of  concerns  for  this  modification  exists,  and 
thus  we  cannot  claim  that  Chiron  provides  strong  architectural  support  for  changing  the  dialogue. 

6.3  Garnet 

6.3.1  Changing  the  Physical  Interaction 

As  can  be  .seen  from  Figure  10,  Garnet  provides  some  architectural  support  for  .separating  dia- 


I .  Note  that  .Serpent  does  provide  some  language  .support  for  this  nuxliricaiiiui.  hut  that  is  not  the  topic  being  con¬ 
sidered  here. 
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logue  concerns  from  application  and  presentation  concerns,  but  that  is  not  its  main  focus.  Garnet 
is  much  more  highly  language-based  than  any  of  the  other  arehiiectures  described  in  this  report. 
As  such,  many  of  the  functions  available  in  Garnet,  such  as  constraints  and  the  KR  object  system, 
are  available  as  integrated  language  services.  In  fact.  Garnet’s  main  empha,sis  is  in  providing  inte¬ 
grated  dialogue  .services,  rather  than  on  physically  isolating  components. 

Still,  Garnet  has  .successfully  isolated  the  PI  component  (the  X 1 1  toolkit  in  Figure  10)  to  a  single 
component,  and  has  hidden  any  XI 1  dependencies  behind  the  LI  component  (Opal  graphics  and 
Interactors).  Garnet  has  strictly  separated  the  PI  component,  and  .so  we  can  claim  that  changing 
this  component  is  supported  by  the  architecture  and  should  be  relatively  easy.  In  fact,  a  Macintosh 
release  of  Garnet  is  planned. 

6.3JZ  Changing  th«  dialog&M 

The  .second  modification  is  not  supported  by  Garnet’s  architecture.  A  dialogue  in  Garnet  is  mono¬ 
lithic,  and  can  involve  any  of  the  language  features  which  Garnet  provides.  Thus,  changing  a 
menu  in  Garnet  involves  locating  and  modifying  the  affected  Lisp  code,  which  may  be  a  difficult 
task  in  a  complex  interface.  Garnet  does  provide  tool  and  language  support  for  this  class  of 
change,  but  as  we  stated  earlier,  that  is  not  the  concern  of  this  paper. 

6.4  PAC 

Though  we  introduced  the  PAC  model  as  a  functiontil  partitioning  only,  it  is  wrong  for  us  to 
ignore  some  of  its  structural  implications  for  user  interface  architectures.  PAC  is  not  realized  as 
toolkit  for  implementing  user  interfaces  (as  are  Serpent,  Chiron  and  Garnet),  but  it  is  worth  con¬ 
sidering  how  a  notional  architecture  ba.sed  on  PAC  would  fare  on  the  benchmark  tasks.  Though  it 
is  clear  that  PAC  did  not  directly  influence  such  mainstay  commercial  interface  builders  such  as 
HyperCard,  Visual  Basic  and  NextStep,  their  similarities  with  regard  to  distributed  dialogue  make 
a  tempting  architectural  comparison.  Also,  Hill’s  Abstraction-Link- View  paradigm  [10],  which 
underlies  the  Rendezvous  ( 1 1]  architecture  for  user  interface  development,  is  strikingly  similar  to 
PAC. 

6.4.1  Changing  the  Physical  interaction 

When  we  look  at  our  sample  modifications  from  PAC's  perspective,  wc  can  .see  that  changing  the 
presentation  (the  physical  interaction  component)  is  not  a  simple  process.  The  physical  interaction 
component  is  distributed  among  the  leaf  agents  in  the  PAC  hierarchy.  Substituting  for  the  entire 
physical  interaction  component  would  mean  that  all  of  the.se  individual  agents  would  have  to  he 
modified.  Assuming  that  the  implementation  of  the  system  rc-spects  the  modularization  of  the 
PAC  design,  none  of  the  individual  changes  would  be  difficult,  but  it  would  require  many  individ¬ 
ual  changes,  which  is  undesirable. 

6.4.2  Changing  the  dialogue 

Changing  the  dialogue  in  a  PAC  model  is  very  different  from  previous  architectures.  The  PAC 
hierarchy  is  compo.sed  of  a  potentially  large  number  of  dialogue  components.  Interaction  widgets 
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like  a  noenu  would  certainly  be  considered  independent  PAC  agents  and  so  the  location  of  the 
modification  would  he  much  easier  to  isolate  and  fix. 

Furthermore,  the  decomposition  of  the  dialogue  into  a  hierarchy  of  cooperating  agents  means  that 
individual  agents  have  a  regular  structure,  a  well-specified  relationship  with  the  rest  of  the  PAC 
hierarchy,  and  are  .self-contained.  These  are  just  the  qualities  that  .support  modifiability:  cu.sc  of 
locating  the  affected  area,  ease  of  understanding  the  proposed  change,  and  separation  of  concerns 
(so  that  a  modification  needs  to  be  made  in  only  one  location,  and  affects  no  other  location). 

Facilitating  the  decomposition  of  the  dialogue  is,  in  fact,  the  main  motivation  for  PAC.  Thus,  wc 
can  confidently  claim  that  PAC*s  architecture  strongly  supports  changing  the  dialogue. 

7  Conclusions  and  Future  Work 

We  have  provided  a  method  for  evaluating  architectures,  based  upon  two  main  ideas:  a  common 
understanding  and  representation  for  architectures,  and  an  analysis  of  an  organization’s  life  cycle 
requirements.  This  method  permits  the  comparison  and  ranking  of  architectures  within  the  context 
of  an  organization’s  particular  needs.  This  sort  of  comparison  has  been  hitherto  quite  difficult. 

The  SAAM  places  strong  demands  on  an  organization  to  articulate  both  its  needs  in  terms  of  the 
attributes  being  evaluated  and  then  to  choose  a  representative  selection  of  tasks  to  demonstrate 
those  needs.  This  is  in  keeping  with  the  purpose  of  the  SAAM  which  is  not  to  criticize  or  com¬ 
mend  particular  architectures,  but  to  provide  a  method  for  determining  which  architecture  sup¬ 
port’s  an  individual’s  or  organization’s  life  cycle  needs.  This  methodology  will  work  for  other 
attributes,  and  will  most  likely  provide  diflfetent  rankings  of  architectures  for  these  attributes.  The 
rankings  with  respect  to  an  attribute  can  be  .seen  as  the  degree  to  which  an  architecture  was 
designed  to  support  that  attribute. 

As  our  understanding  of  this  topic  is,  as  yet,  insufficient  to  allow  for  metrics  by  which  we  might 
more  precisely  evaluate  attributes  in  term  of  architectures,  we  simply  provide  ways  to  analyze, 
compare  and  rank  the  architectures  themselves.  believe  that  the  work  of  Henry  and  Kafura  |9| 
on  information  fiow  points  the  way  to  an  analysis  technique  for  architectures,  but  it  must  he  aug¬ 
mented  by  techniques  for  measuring  the  understandability  and  consi.stency  of  architectures. 

We  must  admit  at  this  point  that  the  analysis  of  user  interface  software  is  not  completely  satisfac¬ 
tory.  Our  analysis  hinged  solely  on  the  allocation  of  function  as  described  by  the  Arch/Slinky 
model  to  the  structure  of  the  various  tools.  Hence,  our  judgement  from  an  architectural  perspec¬ 
tive  depended  on  whether  a  tool’s  .structure  localized  some  logical  function  in  the  domain.  But 
localization  is  not  the  only  concern  when  considering  modifiability.  As  we  already  mentioned,  u 
tool  may  provide  language  .support  for  further  .soxicturing  within  a  logical  component  (c.g..  the 
U.SC  of  .Slang  in  Serpent  to  specify  dialogue  behavior  in  the  dialogue  controller).  Furthermore,  wc 
have  not  taken  into  the  knowledge  that  structural  components  have  of  each  othez  even  though  the 
structural  diagrams  .show  data  and  control  relation.ships.  Clearly,  our  analy.sis  of  modifiability  is  at 
be.st  incomplete. 

We  mu.st  also  note  an  apparent  tautology  in  our  arguments.  We  pre.sented  the  canonical  domain 
partitioning  for  u.scr  interface  software  and  then  expre.ssed  benchmark  modifications  in  terms  of 
that  partitioning.  It  is  not  surprising  that  tools  whose  structure  mirrored  the  canonical  partitioning 
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fate  better  with  respect  to  modifiability.  This  suggests  that  domain  partitioning  is  dependent  on 
software  quality  as  well.  If  we  were  U)  extend  our  analyses  to  other  qualities,  we  might  very  need 
a  different  canonieal  partitioning.  In  fact,  this  might  explain  the  dilTerence  between  the  Arch/ 
.Slinky  model  and  PAC — they  were  suggested  with  diftereiu  software  qualities  in  mind.  Arch/ 
Slinky  is  clearly  motivated  by  separation  between  its  five  logical  components.  PAC  suggests  that 
separation  between  application  and  presentation  is  secondary  to  the  separation  of  u.ser-specilic 
conceptual  objects  which  compri.se  the  individual  PAC  agents. 
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